Speed up memo navigation: loading skeleton + parallel fetches - #62

Clicking a memo in production felt unresponsive. Investigating turned up two separate causes.

The click felt dead

The memo route reads cookies (primeAdminPreviewToken + getCurrentUser), so it renders dynamically on every request. With no loading boundary, its prefetch payload was empty:

prefetch RSC on prod → 239 bytes    (nothing usable)
actual RSC on click  → 55,210 bytes

So a click did a full origin round trip while React kept the previous page on screen — no spinner, no skeleton, nothing until the whole memo rendered. Adding loading.tsx makes the skeleton part of the statically prefetchable shell (239 bytes → ~30KB), so a hovered link paints instantly on click.

This is compensation, not a cure — see "Not addressed" below.

The render was needlessly serial

fetchMemo and fetchMemos are independent but ran one after the other, and fetchMemos paged through all 65 memos one request at a time before fetching /team. Now page 1 establishes the page count, the rest go out together, and /team starts up front since it never depended on the pages.

Measured against the live API, 3 runs each, identical output (65 memos, 81 team members):

This also fixes a latent bug: the pagination loop mutated a single shared queryParams object and set page on it. Safe only because the calls were sequential — parallelizing as-written would have had every request racing on the same key. Each page now builds its own params.

The skeleton

Mirrors the real layout at the same widths and spacing so nothing shifts on swap. Chrome that's identical on every memo is rendered for real — the Key Messages frame, its eyebrow and 01/02/03 numerals, the Signpost's accent rule, track, dots and share buttons — with placeholders only where per-memo content goes. Primitives (.skeleton-bar, -strong, .skeleton-delay-*) live in globals.css for reuse; light grey from the charcoal ramp, with a sweep rather than an opacity pulse. Reduced-motion is already handled globally.

Behaviour change worth a look

Related memos are now non-fatal (fetchMemos().catch(() => [])). Previously a failure there would 500 the entire memo page over a decorative two-item sidebar. This matches how /team failures were already handled in the same file. A bad slug still 404s. Happy to make it fatal again if you'd rather.

Testing

• tsc --noEmit and eslint clean
• Dev server: memo renders with correct title and related section; /memos still lists all 65
• Prefetch payload confirmed to carry the skeleton; skeletonSweep confirmed in compiled CSS
• Not visually reviewed — no browser available in the session that wrote this. Worth eyeballing on throttled network before merge, particularly the grey bars inside the warm Key Messages box.
• npm run build fails on /tracker, which prerenders against localhost:3000. Pre-existing and unrelated; the memo routes compile.

Not addressed

Three larger items from the same investigation, in rough order of impact:

1. The route is dynamic at all. Moving the cookie read out of the page body would make it statically prerendered and CDN-cacheable, turning a prefetched click into a zero-network navigation. Needs a decision on how draft preview should work.
2. 65 memos fetched to show 2 related ones. Should be a filtered query or streamed behind <Suspense>. This PR made it faster, not smaller.
3. /team takes ~1.1s upstream and is on nearly every page — now the long pole in the parallel version.

🤖 Generated with Claude Code